Migrating from DCT on Kubernetes to DCT appliance

Migrating from DCT on Kubernetes to the DCT appliance works by performing the following steps:

  1. Provision and configure a DCT appliance

  2. Backup DCT on Kubernetes

  3. Restore the backup onto the DCT appliance

  4. Stop DCT on Kubernetes

The DCT backup may include sensitive data such as passwords to connect to engines, API keys to connect to hyperscale orchestrators, and personally identifiable information. While the data is encrypted in transit, make sure that you store the backup in an appropriate location. Make sure that the backup location adheres to your company policy on access control and encryption at rest. It is a best practice to perform the backup operation from a dedicated server, and not from an operator machine. For this reason, the DCT appliance does not provide a web user interface for the backup but mandates the use of API calls scripting.

The instructions provided here do not apply when using an external database. Contact support if you need to migrate a DCT Kubernetes instance connected to an external database.

Provision and configure a DCT appliance

Follow the Install and upgrading (OVA) instructions to configure a new DCT appliance. Make sure the allocated storage space for metadata is larger than the size of the persistent volumes of the DCT on Kubernetes installation to migrate, and that the DCT appliance can connect to all registered engines.

The DCT appliance must be of the same or a more recent version than the DCT on Kubernetes instance, which is migrated, and at the minimum version 2025.2.0.0.

Backup DCT on Kubernetes

Download the dct-support-tools from the downloads site. Once the file is downloaded, untar the file and open the bacup-restore directory to find the backup_restore.sh and appliance_backup_restore.sh scripts.

Copy 
% tar -xzvf dct-support-tools-02132025.tar.gz
% ./
% ./backup-restore/
% ./backup-restore/README
% ./backup-restore/backup_restore.sh
% ./backup-restore/appliance_backup_restore.sh
% ./support-bundle/
% ./support-bundle/collect_bundle.sh
% ./support-bundle/README
% ./VERSION
% cd backup-restore

Transfer the backup_restore.sh and appliance_backup_restore.sh scripts to the machine where you have permissions to execute kubectl commands against the DCT pods. You must install the bash shell to run the backup_restore.sh script, as well as the zip/unzip utilities. You must also have the curl command installed to run the appliance_backup_restore.sh script.

Make sure DCT on Kubernetes is running and execute the backup_restore.sh script. The script may need to run with sudo if root permissions are needed to run the kubectl commands. Use the -n flag and pass the namespace (if not using the default dct-services), and redirect the script output to the desired backup location. The size of the backup depends on the size of the DCT data to be backed up but is typically in the 1GB to 10GB range. The script may take several minutes to execute and does not print anything to the console in case of success.

Copy 
% /bin/bash backup_restore.sh -n dct-services > dct-migration-backup1.zip

Restore the backup onto the DCT appliance

This is a destructive operation. The DCT application data on the DCT appliance will be permanently erased.

To restore the DCT backup, the file must be uploaded to the resources/json/delphix/system/downloadAppBackup API endpoint of the DCT appliance, authenticated as a system user.

The appliance_backup_restore.sh script can be used to ease the workflow. If network access to the DCT appliance from this machine is impossible, move the migration backup and the appliance_backup_restore.sh script to a machine which can connect to the DCT appliance over the network to perform API calls.

Execute the script with the following flags:

  • -n appliance hostname

  • -l backup location

  • -u system username (sysadmin)

  • -p system user password

  • -k If necessary, disable TLS certification verification

The script takes several minutes to execute.

Copy 
% /bin/bash dct_appliance_restore.sh -n my-dct-appliance.company.co -l dct-migration-backup1.zip -u sysadmin -p sysadmin
{"type":"OKResult","status":"OK","result":{"type":"APISession","version":
{"type":"APIVersion","major":1,"minor":4,"micro":3},"locale":null,"client":null},"job":null,"action":null}
session established... logging in
{"type":"OKResult","status":"OK","result":"USER-1","job":null,"action":null}
logged in
restoring DCT ...
{"type":"OKResult","status":"OK","result":"","job":null,"action":"ACTION-119"}

At this point, both DCT on Kubernetes and the DCT appliance are pulling information from (and can manage) registered engines.

Stop DCT on Kubernetes

Connect to the DCT appliance using the API keys or credentials which have been migrated from DCT on Kubernetes and familiarize yourself with the DCT appliance. If necessary, the backup and migrate (restore) process can be repeated with the same instructions (restore will override the DCT application data on the DCT appliance).

Once you are ready to stop using DCT on Kubernetes, uninstall DCT on Kubernetes with the helm delete command:

Copy 
% helm list
NAME              NAMESPACE    REVISION    UPDATED                                STATUS      CHART                    APP VERSION
dct-services    default      1           2025-03-04 13:12:55.87833 +0100 CET    deployed    delphix-dct-2025.0.1    latest
% helm delete dct-services
release "dct-services" uninstalled